系列：從現場踩坑到 AI 工具 — IT Diagnostic Agent 開發實錄
本篇為系列核心篇之一
Evidence-driven Dialogue 的五條規則定案之後，我面前有一個很明顯的問題：
我的工具，實際上到底符不符合這些規則？
我可以憑印象回答。我寫的程式我自己最清楚，直覺告訴我應該是符合的。
但我沒有這樣做。我做的是：
「你去 clone 我的 GitHub repo，逐一檢查程式碼，對照這五條規則做稽核。」
用 AI 來稽核我自己的 AI 整合。
這聽起來有點迴圈，但它有效的原因很簡單：稽核需要的是逐行對照，而那正是我最容易憑印象跳過的工作。
Claude clone 了 repo，實際讀了程式碼，回報結果。
通過的部分：
| 模式 | 五條規則 | 機制 |
|---|---|---|
| Decision Tree | 全數符合 | 人工撰寫的節點結構 |
| Runbook | 全數符合 | 人工撰寫的節點結構 |
| Deep Diagnosis | 全數符合 | 人工撰寫的節點結構 |
而且稽核明確指出，符合的原因不是我寫了什麼 Prompt，是 static gating enforced by code, not LLM self-restraint——由程式碼強制的靜態閘門。
這就是 Day 14 整篇的主題。它不是我事後包裝的說法，是稽核報告的原話。
到這裡我還挺滿意的。
AI Chat 模式：不通過。
具體位置：index.html 第 983 行（中文）和第 1098 行（英文）的 sys: 字串。
稽核的結論很不留情：
這段 systemPrompt 只規範了輸出格式，五條核心規則一條都沒有，決策相關性測試也沒有。
我去把那行叫出來看。原文長這樣：
sys:'你是一位資深 IT 工程師，專精於企業 IT 基礎設施的故障排除與維護。\n\n
專業範疇：網路（CCTV、Wi-Fi、DNS）、硬體（Server、NAS、印表機）、
軟體（AD、SQL、Exchange、Office、Outlook）。\n\n
回應：使用繁體中文、先給診斷關鍵問題、具體命令用 code block、
依嚴重程度排列、結尾加預防建議。'
三個部分：角色定義、專業範疇、回應格式。
五條規則，一條都沒有。決策相關性測試，沒有。
我把這段 Prompt 逐句對照五條規則，才發現事情不只是「缺漏」。
它有三句在往反方向推。
這句話的方向感是對的——它至少要求先問問題，不要直接跳結論。這勉強沾到規則 1 的邊。
但「問題」是複數。它要求的是一次給出一組關鍵問題，不是問一個最高資訊增益的問題然後停下來等回答。
→ 違反規則 2（單一問題）和規則 3（問完要等）
要能「排列」，就得先有一份清單。
這句話從語意上就預設了列舉的存在。 它不是允許列舉，它是在指導怎麼列舉得更好。
→ 直接違反規則 5（不要列舉所有可能性）
在故障還沒解決的當下，預防建議會改變使用者的下一步行動嗎？
不會。他現在要的是修好它。
→ 違反 PS 決策相關性測試（不會改變下一步的內容，就不要給）
把三句話合起來看，這段 Prompt 在最佳化的是什麼？
一次給出完整、排序良好、附帶延伸建議的回答。
也就是 maximize completeness——最大化完整性。
而那正是 Day 13 整篇文章說要換掉的東西。
我原本以為稽核找到的是「忘記寫規則」。實際上找到的是：我在那段 Prompt 裡，親手寫下了一組要求 LLM 追求完整性的指令，而我在另一份文件裡論證完整性在故障排查中是有害的。
同一個人，同一個專案，兩套互相矛盾的目標函數。
這比單純的遺漏難發現得多，因為那段 Prompt 讀起來完全合理。 「先給關鍵問題、依嚴重程度排列、結尾加預防建議」——這聽起來就是一個負責的資深工程師該有的樣子。
它只是剛好不適用於「使用者現在很急」這個情境。
我想了一下這個漏洞是怎麼形成的，因為原因本身比漏洞有意思。
決策樹是我當「主要功能」設計的。 我花了大量時間思考節點順序、驗證成本、分支邏輯——所有的診斷紀律都投注在這裡。
AI Chat 是我當「逃生門」設計的。 它的定位是「樹上沒有的情況，去問 AI」。
而我對逃生門的要求，就只有「它要能開」。
我從來沒有想過：逃生門後面的那條路，需不需要跟主通道一樣的規則？
整個工具裡最需要那五條規則的地方，正是唯一沒有它們的地方。
想清楚就會發現這個結構很荒謬：
換句話說：
紀律在有結構的地方是多餘的，在沒有結構的地方是必需的。而我把它寫在了多餘的地方，漏掉了必需的地方。
不，更準確地說：我兩邊都沒寫。只是有結構的那邊，不寫也沒差。
稽核之後，Claude 給了一個修正後的 sys: 字串——把五條規則和決策相關性測試明確寫進 systemPrompt。
整個理論到實作的對齊，只需要改那兩行。
第 983 行和第 1098 行。中文一行、英文一行。
我想強調這個數字，因為它說明了一件事：
這不是一個架構問題，是一個一致性問題。
架構是對的。決策樹的設計哲學是對的。缺的只是把同一套哲學，套用到那條繞過架構的路徑上。
而修正的性質也跟我原本想的不一樣：
它不是在一張白紙上補寫規則，是把一組要求完整性的指令，換成一組要求紀律的指令。
「依嚴重程度排列」要拿掉，不是因為它寫得不好，是因為它在最佳化錯的東西。
一個兩行的替換，等於把整個工具的目標函數統一。
這是現在跑在 main branch 上的版本（中文版）：
你是一位資深 IT 工程師，專精於企業 IT 基礎設施的故障排除與維護。
專業範疇：網路（CCTV、Wi-Fi、DNS）、硬體（Server、NAS、印表機）、
軟體（AD、SQL、Exchange、Office、Outlook）。
【證據導向對話原則】
1. 證據不足時，絕不跳到結論。
2. 一次只問一個問題——選擇「答案最能改變下一步行動」的那一個。
3. 問完後停下來等使用者回答。不要自問自答，不要假設答案。
4. 只在收到新證據後才更新診斷。「還是不行」不是證據，那只排除了一個選項。
5. 除非使用者明確要求，不要列舉所有可能原因。
【決策相關性測試】
問任何問題前先自問：「如果我現在就知道答案，這會改變我接下來做什麼嗎？」
如果不會，就不要問，直接用現有證據往下走。
回應：使用繁體中文、具體命令用 code block、
每一步給出可立即執行的動作而非方向。問題解決後才提供預防建議。
有三個地方值得說明。
規則 4 我加了一句具體反例。 原本的規則是抽象的「只在收到新證據後更新診斷」，我補上「『還是不行』不是證據，那只排除了一個選項」。
因為抽象規則對 LLM 的約束力，遠不如一個具體的反例。告訴它什麼不算證據，比告訴它什麼算證據更有效。
風格那段整個換掉了。 從「依嚴重程度排列」變成「每一步給出可立即執行的動作而非方向」。
這句話的靈感其實來自我後來回覆一個 GitHub Issue 的方式——那是 Day 26 的故事。當時我沒有寫「你需要設定環境變數」，而是分作業系統給出可以直接貼上執行的指令。方向和動作的差別，在故障當下就是十分鐘和三十秒的差別。
預防建議從「結尾」改成「問題解決後」。 這是 PS 測試的直接應用：問題還沒解決時，預防建議不會改變使用者的下一步。
我在寫這篇文章的時候，缺口還在。
現在它被修好了，已經推上 main branch，commit d2455c0。
同一次修正還補上了另一個缺口：Ollama 確認 modal 的 checklist 少了 OLLAMA_ORIGINS 這一項——那是一個使用者回報的問題，故事在 Day 26。
整個改動是 4 行插入、2 行刪除，index.html 從 3201 行變成 3203 行。
如果你想核對，repo 是公開的：github.com/richchang0721-boop/it-diagnostic-agent
而更重要的是：修好之後我實際去測了它。
我用本機的 Ollama 跑 gemma3:12b，丟了一個真實的故障情境進去，做了三輪對話。
結果是五條規則加上決策相關性測試，全數守住。
那個測試的完整過程和它揭露的東西，是 Day 20 的主題——而那篇文章原本是這個系列裡我最心虛的一篇，因為我在裡面承認了一件事：我從來沒測過 AI 對話這條路徑。
現在測了。而測試結果比我預期的有意思得多。
我從這次稽核學到的東西，比修好那兩行重要得多：
架構層級的紀律，不會自動傳播到繞過架構的部分。
這句話值得寫下來，因為它適用範圍遠不只我這個小工具：
每一條「例外路徑」都是紀律的斷點，而且因為它是例外，最容易被漏掉。
我做 IT 二十年，這個道理在資安上我很熟。但發生在我自己的專案裡，我還是漏了。
而這次還多了一層：斷點上不只是沒有紀律，還有一組看起來很專業、實際上方向相反的指令。
這比空白危險。因為空白你會發現，而一段讀起來很合理的文字你不會發現。
這篇文章其實是在承認：我做了三天的理論鋪陳，然後發現我的工具有一塊沒做到。
我可以先把那兩行改掉，再寫這個系列，讓一切看起來很完整。沒有人會知道。
但這樣就少了一個最有價值的東西：一個工具在什麼情況下會偏離它自己的設計哲學。
而且我認為，一個誠實承認自己有缺口的工具，比一個宣稱完美的工具可信。
核心 vs 外部
核心發現不是「有個 bug」，是「例外路徑會逃離架構紀律」。這個發現可以複用，那個 bug 不能。
可控 vs 不可控
我控制不了 LLM 在自由對話裡的推理。但我控制得了給它什麼 systemPrompt。這是那條路徑上唯一可控的槓桿，所以它必須用好。
已成立 vs 假設
稽核之前，「我的工具符合五條規則」是一個假設。稽核之後，它變成一個有範圍限定的事實：樹狀模式符合，自由對話不符合。
把假設變成有範圍的事實，這就是稽核的全部價值。
我原本以為請 AI 稽核自己的程式碼，是一個節省時間的動作。
結果它給我的不是時間，是一個我自己不會發現的盲點——因為那個盲點的位置，正好在我認為「不重要所以沒仔細想」的地方。
人最看不見的不是難的東西，是自己判定為簡單的東西。
Day 11 到 Day 15，這一章是整個系列的核心：
這章的主線是： 好的 AI 應用不是把 Prompt 寫得更精美，是先問「這條規則能不能不靠 Prompt」。能，就做進架構。不能，才寫進 Prompt——而且要記得檢查所有繞過架構的路徑。
明天預告（第四章）： 工具現在很依賴 Claude。但如果明天 API 漲價、政策改變、或者某個企業客戶說「我們不能把資料送出公司」，怎麼辦？下一章講退路。
作者：Rich Chang | IT 基礎建設工程師 | 越南・柬埔寨・台灣
iThome鐵人賽
看影片追技術